Add native reftable repository support - #2096

RefCursor is per repo family and reftable_entries persists across commands. replace_reftable_stack_entries (src/daemon/ref_cursor.rs:273-289) only clears entries whose path equals the stack it just re-read, so after commands from both the main worktree and a linked worktree the map holds two distinct HEAD keys: head_key(common_git_dir) (materialized from the common stack) and head_key(linked_git_dir) (from .git/worktrees/<name>/reftable).

refs_at_command_start then iterates self.reftable_entries.values() and, for every group whose reference == "HEAD", resolves it with head_position — the offset captured for the current command's worktree — and inserts it under the literal key "HEAD". Because HashMap iteration order is unspecified, whichever HEAD group is visited last wins, so the returned snapshot can carry another worktree's HEAD OID.

The files-backed path does not have this problem: refs_at_reflog_start_offsets (src/daemon/ref_cursor.rs:2672-2695) iterates cmd.reflog_start_offsets, which only ever contains the current worktree's HEAD key.

The new integration test reftable_linked_worktree_uses_its_own_head_log does not exercise this because every command runs in the linked worktree, so common-stack HEAD entries are never materialized (main_worktree stays false and had_common_head stays false).